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Summary 

A state-of-the-art computational facility for aircraft 
flight control design, evaluation, and integration called 
CONDUIT (Control Designer’s Unified Interface) has 
been developed. This paper describes the CONDUIT tool 
and case study applications to complex rotary- and fixed- 
wing fly-by-wire flight control problems. Control system 
analysis and design optimization methods are presented, 
including definition of design specifications and system 
models within CONDUIT, and the multi-objective 
function optimization (CONSOL-OPTCAD) used to tune 
the selected design parameters. Design examples are 
based on flight test programs for which extensive data are 
available for validation. CONDUIT is used to analyze 
baseline control laws against pertinent military handling 
qualities and control system specifications. In both case 
studies, CONDUIT successfully exploits trade-offs 
between forward loop and feedback dynamics to signifi- 
cantly improve the expected handling qualities and 
minimize the required actuator authority. The CONDUIT 
system provides a new environment for integrated control 
system analysis and design, and has potential for signifi- 
cantly reducing the time and cost of control system flight 
test optimization. 

Introduction 

The design, integration, and flight test development of 
flight control systems for modern fixed- and rotary-wing 
aircraft presents a challenging multidisciplinary task that 
factors significantly in the overall time and cost of aircraft 
development (ref. 1). Comprehensive specifications such 
as those embodied in ADS-33C (rotorcraft) (ref. 2), 
MIL-STD-1797A (fixed-wing) (ref. 3), MIL-F-9490D 
(general control system characteristics) (ref. 4), and 
sophisticated time- and frequency-domain evaluation 
techniques are applied to ensure desired performance and 
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handling qualities and to minimize flight test tuning of 
highly augmented modern combat aircraft. The overlap of 
flexible airframe modes and high-bandwidth control laws 
drives the requirement for incorporating increasingly 
higher-order analytical and identification-derived simu- 
lation models (ref. 5) and automated gain selection 
techniques in the control system design process (ref. 6). 

The control law design and evaluation for a single design 
point is made very laborious as a result of the numerous 
(often competing) design specifications and constraints. 
This process must be repeated for the tens (or even 
hundreds) of configuration design points that are evalu- 
ated for a full flight envelope control system. Further, the 
control system design engineer must continually update 
and integrate improvements in the mathematical models 
as hardware test data become available (ref. 1). Often, 
design specification changes are also introduced during 
the course of aircraft development, which as with the 
other changes require control law retuning across the 
flight envelope. Since current tools generally do not 
facilitate the study of the trade-offs between competing 
specifications, hardware characteristics, and performance 
metrics, the final design may not make the best use of 
available control authority for modern control-configured 
vehicles. The failure to consider such trade-offs can 
compromise control system performance and handling 
qualities. Clearly, sophisticated interactive computational 
tools are needed to integrate the many aspects of the flight 
control design process. 

The U.S. Army Aeroflightdynamics Directorate in 
conjunction with NASA, the University of Maryland, and 
California Polytechnic State University (San Luis Obispo) 
have jointly developed a state-of-the-art computational 
facility for aircraft flight control design and evaluation 
referred to as CONDUIT. As the acronym implies, 
CONDUIT (Control Designer’s Unified Interface) 
provides an environment for design integration and 
data resource management (fig. 1). CONDUIT is a 
sophisticated “associate” that provides comprehensive 
analysis support and design guidance to a knowledgeable 
control system designer; it is not a “tum-the-crank” 
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Figure 1. CONDUIT control system integration and design evaluation process . 


optimization program. CONDUIT builds on an earlier 
design tool, GIFCORCODE, developed under the same 
cooperative effort (ref. 7). 

This paper describes the CONDUIT tool and case study 
applications to complex rotary-wing design and fixed- 
wing problems. The control system analysis and design 
optimization methods are presented first, including the 
definition of design specifications and system models 
within CONDUIT, and the multi-objective function 
optimization approach (CONSOL-OPTCAD) used to 
tune the selected design parameters. The rotorcraft flight 
control design example is based on the analysis and 
optimization of control laws for the RASCAL UH-60A 
helicopter. The NASA/Army RASCAL (Rotorcraft 
Aircrew Systems Concepts Airborne Laboratory) is 
equipped with a programmable fly-by-wire flight control 
system to support a range of research programs in flight 
control, simulation, and advanced displays (ref. 8). 
CONDUIT is being used to evaluate the baseline control 
laws and control system hardware, as provided by the 
RASCAL flight control contractor (Boeing Helicopter), 
versus the ADS-33C specifications. Then the selectable 
system gains are optimized to improve system perfor- 
mance and handling qualities. The CONDUIT results are 


based on dynamic response models of the UH-60A 
helicopter obtained from system identification, and thus 
are expected to be highly representative of actual 
RASCAL performance without further significant 
modification. 

The second design example is based on the X-29A high 
performance fixed-wing aircraft. A unique feature of this 
fly-by-wire aircraft is its forward-swept wing configura- 
tion, which renders the bare airframe highly unstable and 
thus potentially more maneuverable than conventional 
configurations. The X-29A was developed by Grumman 
and flown at NASA Dryden Research Center (ref. 9). 
Extensive flight data and handling-qualities results are 
available in the literature, including comparisons with 
handling qualities and servo-loop specifications, and 
design optimization studies. The results presented herein 
suggest that CONDUIT can provide options for consid- 
erable improvement in the X-29A handling qualities and 
servo-loop characteristics. 

Key Features of CONDUIT 

CONDUIT is built on top of the highly flexible 
MATLAB/SIMULINK system modeling and analysis 
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environment (ref. 10), which includes a graphical block 
diagram editor and block-diagram-to-code features. 
CONDUIT makes extensive use of the MATLAB graphi- 
cal user interface (GUI) coding features to create a true 
interactive graphical user interface for problem setup and 
pushbutton program operation (fig. 2). 

The user graphically selects the desired handling qualities 
and flight control system specifications from a library of 
standard fixed- and rotary-wing specifications, or builds 
new specifications from generic time- and frequency- 
domain specifications. Specifications are wired to the 
simulation block diagram via a graphical editor, thereby 
avoiding any manipulation of the extensive MATLAB 
“m” files used for each specification. The user can click 
on and bend the specification boundary curves and the 
system automatically updates the relevant defining 
equations. 

Compliance with all active specifications is graphically 
displayed on the criteria with a single pushbutton 


command, thus significantly streamlining the system 
evaluation process. A key feature of CONDUIT is that a 
single mouse click on any of the specifications brings up 
an extensive set of supporting plots that present all of the 
relevant analyses associated with the specification. A 
state-of-the-art multi-objective function optimization 
environment (CONSOL-OPTCAD) (ref. 1 1 ) is integrated 
into CONDUIT to allow the user to tune selected design 
parameters (e.g., gains, time constants) for compliance 
with the active design specifications, or to update control 
laws for changes in modeling data and design specifica- 
tions. An important application of the automated tuning 
capability is for examining the trade-offs between control 
system performance and actuator authority requirements, 
and between competing specifications. Finally, the 
CONDUIT problem definition and all results are stored 
and organized in a database for easy retrieval and 
comparative studies by the user. 
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Figure 2. Collage of CONDUIT displays. 
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CONDUIT Evaluation and Design Process 

Overview 

In developing CONDUIT, we have taken the view that 
the aircraft developer has already conducted a preliminary 
design study to determine an appropriate control law loop 
architecture. Alternatively, the selection of the control 
law architecture may have been based predominantly on 
historical precedent within a particular company. In either 
case, the control system analyst will use CONDUIT to 
evaluate the baseline design and to tune the design 
parameters for best system behavior. 

CONDUIT has two basic modes of operation: setup and 
run. Within CONDUIT’S setup mode, the user accesses 
SIMULINK to define (or import) the simulation mathe- 
matical model and control law architecture. The aircraft 
response models are obtained from analytical simulations 
or system identification results derived from flight/ground 
test data. The main aspect of problem setup in CONDUIT 
is the graphical selection and wiring of the handling 
qualities and servo-loop specifications. The user must 
also set up a small initialization file to define problem- 
dependent constants such as simulation time-step and test 
input signals. 

In CONDUIT’S run mode, the user establishes starting 
values for the design parameters and conducts an initial 
evaluation of all of the system specifications with the 
push of a single button. Supporting plots are examined for 
further insight into system behavior. Then the user can 
easily tune the design parameters manually with rapid 
access to all of the linear and nonlinear response implica- 
tions, or use the automated tuning feature to achieve 
Level 1 (“desirable region”) performance of all of the 
specifications. Finally, the optimization feature of 
CONDUIT can be exercised to tune the design parameters 
for best performance relative to a selected set of objective 
criteria. 

The following sections give more detailed information on 
CONDUIT operating features. 


a. Problem Setup in CONDUIT 

The first step of the problem setup in CONDUIT is the 
definition of the aircraft dynamics and control law 
architecture within SIMULINK and the selection of 
appropriate design specifications from the available 
libraries. The aircraft aerodynamic model is commonly a 
high-order linearized state-space representation that is 
numerically extracted from a complex nonlinear simula- 
tion model. System identification flight tests are often 
conducted early in the aircraft development program to 


validate and update the simulation characteristics 
(ref. 12). The control law model must include port limits 
(e.g., for a limited authority fly-by-wire system) and 
actuator rate and displacement saturation limits. These 
nonlinear elements are vitally important in determining 
aggressive maneuvering behavior for moderate and large 
control inputs. 

There are currently five graphical libraries 
comprising over 50 specifications in CONDUIT: 

• rotorcraft in hover/low speed flight (ref. 2) 

• rotorcraft in forward flight (ref. 2) 

• fixed-wing lateral/directional characteristics (refs. 3 
and 13) 

• fixed-wing longitudinal characteristics (refs. 3 
and 13) 

• general system characteristics (ref. 4) 

The user scrolls through the libraries (e.g., fig. 3) and 
selects, using the mouse, the specifications appropriate to 
the problem. 
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Figure 3. Example window from the handling quality 
specification libraries. 
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Three levels of compliance are defined for each 
specification, following the handling-qualities levels 
convention (refs. 2 and 3). In the Level 1 region, the 
aircraft characteristics are “satisfactory without improve- 
ment/’ This is the desirable performance region and is 
indicated in blue on the color monitor (darkest shade 
in black and white). The bordering region is Level 2, 
“deficiencies warrant improvement.” This is the adequate 
performance region, and may be acceptable under 
degraded system operations or for flight outside the 
baseline envelope. This region is indicated in magenta 
on the color monitor (lightest shade in black and white). 
The final region is Level 3, “deficiencies require improve- 
ment.” This is the inadequate performance region, where 
the mission task will be compromised. This region is 
indicated in red on the color monitor (intermediate shade 
in black and white). 

The splines that define the boundaries between each level 
can be graphically altered to update the libraries with new 
specifications or to evaluate the sensitivity of a design to 
changes in the criteria. Additionally, CONDUIT accom- 
modates the uncertainty in the simulation mathematical 
model and changes in actual flight condition relative to 
the reference condition by allowing the user to include a 
“design margin” as illustrated in figure 4. Thus, in flight, 
the control system performance can degrade into this 
design margin without entering the Level 2 region. 

The specifications are then “wired” to the SIMULINK 
simulation model using a graphical “spec editor.” Here, 
the user declares each specification to belong to one of 
the following four classes: (1) hard constraint, (2) soft 
constraint, (3) performance criterion, or (4) check 

BW03iib: Bandwidth & Time Delay 
All Other MTEs/UCE=1 /Fully Attended (Pitch) 



Bandwidth [rad/sec] 


Figure 4. Bandwidth specification including a 0.6 design 
margin. 


specification only. The selection of specification class 
defines the solution strategy for the CONSOL-OPTCAD 
optimization process. The input and output port connec- 
tions for each specification are indicated in an informa- 
tion box in the spec editor, and are w ired to the simulation 
block diagram with pull-down menus. 

b. Baseline Evaluation 

The user requests a complete evaluation of system 
behavior against the specifications by pressing a single 
“EVAL” button. CONDUIT executes the MATLAB 
scripts associated with each of the selected specifications 
and displays the results on the graphical specification 
plane. Multiple layers of supporting analysis plots are 
available to the user by simply clicking on the respective 
specification (fig. 5). This feature gives the control 
system designer rapid insight into system behavior and 
the effects of control system changes on specification 
compliance. 

c. Performance Comb 

A distance algorithm in CONDUIT translates the location 
of the design point on each of the graphical specification 
criteria to a numerical rating. This normalized rating is 
based on the closest distance from the Level 1/2 and 
Level 2/3 border splines and the local width of the 
Level 2 region (dl, d2, and d3, respectively, in figs. 6 
and 7). A rating of “1” indicates that the design point lies 
on the Level 1/2 border spline. A rating of “2” indicates 
that the design point lies on the Level 2/3 border spline. 
The numerical ratings for each specification are displayed 
on a performance comb (Pcomb) bar chart as showm in 
figure 8. The color of the bars displayed on the monitor 
corresponds to the color-coding of the Level 1, 2, or 3 
region that the data lie in. Figure 8 shows the mapping 
of the specification results into the Pcomb chart, and 
indicates the relative degree of compliance with each of 
the specifications. These numerical ratings are used by 
CONSOL-OPTCAD to tune the design, as is discussed in 
the next section. 

d. Design Tuning 

The user graphically selects design parameters that 
will be used by CONDUIT in the tuning process. Typi- 
cally these are the feedback and feedforward parameters 
(e.g., gains, time constants) that are scheduled as a 
function of flight condition in modern fly-by-wire 
aircraft. CONDUIT feeds the design parameters and 
constraints in the form of a “pseudo C program file to 
the optimization engine CONSOL-OPTCAD. 
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Figure 5. Example of supporting plot that explains the results displayed on specification . 


The theoretical basis for CONDUIT’S automated tuning 
function rests on the assumption that any individual 
specification can be adequately approximated by a 
smooth (at least twice differentiable) function, mapping 
the design parameters into a real number. For example, if 
x g Q. c R n , where x is the n- vector of parameters and Q. 
is the set of admissible parameter values, then fj(x) is the 
specification. The specification can be a performance 
criterion, meaning that the goal is to minimize fi(x) over 
all x_e Q, or it can be a constraint, meaning f|(x) < (3j (pj 
real) in order for x to be an admissible value for the 
design parameters. 


The design problem, once it has been fully formulated, 
will be solved iteratively starting from some initial guess, 
Xq, for the design parameters. For any constraint that is 
not satisfied at Xo (e.g., fj(*o) > Pj) an obvious way to 
proceed is to treat that constraint temporarily like a 
performance criterion and try to find an x that minimizes 
fj(x) subject to x e Q. In attempting to minimize fj(x), the 
computer will either move to an x that satisfies fj(x) < Pj 
or show that no such solution exists. Thus constraints and 
performance criteria are equivalent until a value of x that 
satisfies the constraints is found. 
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Figure 8. The Pcomb displays the mapping the between graphical specifications and numerical ratings. 


The previous paragraphs show that a typical design 
problem can be mathematically formulated as a con- 
strained multi-criterion parametric optimization problem. 
In most such problems it is necessary to trade off among 
competing criteria. For example, in most control design 
problems, increasing the feedback gain improves tracking 
but degrades gain margin. In order to use the computer to 
assist in solving such a design problem it is necessary to 
reduce the multiple criteria to a single criterion that 


captures these trade-offs. It is well known that no 
weighted linear combination of criteria can do this. 
Mathematically, 


min 


in 

^<*i/j(x), 0<aj<oo, a i real 


i=l 


always occurs at an x*(a) satisfying 






( 2 ) 


min f\ (x) for some i , 1 < i < m 

xeQ. 

In other words, the value of x that minimizes any linear 
combination of performance criteria always equals the 
value of x that minimizes one of the criteria. This is 
illustrated in figure 9(a) for a simple problem involving 
two design specifications and one design parameter. The 
weights can only change which specific criterion is 
optimized. All the others are ignored and no trade-off 
occurs. 

A good way to combine the multiple performance criteria 
so as to balance competing objectives is as follows: 

min max oq/j(x) , 0<oq, cq real (3) 
xeO\l<i<m J 

The great advantage of this formulation is that the 
optimal value of x can be placed anywhere in the region 
of the parameter space bounded by the minima of the 
individual criteria by appropriate choice of the a\. This is 
shown for the simple example in figure 9(b). Thus any 
reasonable choice of the aj produces a trade-off among 
the specifications. The CONDUIT distance algorithm 
automatically normalizes the weightings for the speci- 
fications, using the natural choice of the width of the 
Level 2 regions. A designer could explore the trade-offs 
by adjusting the relative widths of the Level 2 regions. 

The min/max formulation of equation (3) reduces the 
complex problem of multiple design criteria to a problem 
of minimizing a scalar performance measure subject to 
constraints. However, solving even the scalar optimiza- 
tion problem is difficult since the criteria values (fj(x)} 
are generally a highly nonlinear function of the design 
parameters (x). CONDUIT employs the CONSOL- 
OPTCAD (ref. 1 1) optimization engine to solve this 
difficult problem. As the iterative solution progresses and 
those fj(x) that correspond to constraints become satisfied 
they change from being performance criteria to being con- 
straints. Conceptually, such satisfied constraints redefine 
D. Thus, at each stage, CONSOL-OPTCAD is trying to 
solve a constrained parametric optimization problem. 

The best algorithm known at this time for solving such 
problems is Feasible Sequential Quadratic Programming 
(FSQP) (refs. 14 and 15). This is the algorithm used by 
CONSOL-OPTCAD. The idea behind FSQP is to 
approximate the original optimization problem by a 
sequence of quadratic programming problems. This 
approximation should result in quadratic convergence 
near the optimum. The word “feasible” refers to the fact 
that the solution continues to satisfy any constraint at 
every iteration after the first one for which the constraint 
is satisfied. 




Figure 9(b). Min/max solution approach used in 
CONSOL-OPTCAD. 

System optimization using CONSOL-OPTCAD is 
conducted in three distinct phases. In Phase 1, the design 
parameters are tuned to ensure that the “hard constraints” 
are satisfied; these are typically absolute (or relative) 
stability in each loop and other Level 1 specifications that 
must be satisfied. Once all of the hard constraints meet 
the Level 1 criteria, the optimization process moves into 
Phase 2 and begins to work on the “soft constraints.” 

Most of the problem’s specifications are declared as soft 
constraints. This choice allows CONDUIT to accept a 
solution that does not strictly meet all of the Level 1 
requirements, but one that reaches the best possible 
compromise for the available actuator authority. If the 
design satisfies all of the Level 1 requirements for the soft 
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constraints, CONSOL-OPTCAD has achieved a “feasible 
solution." Since any design that resides in the Level 1 
region is feasible, Phase 2 optimization actually reaches 
a “family' 1 of design solutions. Now the optimization 
process enters Phase 3. 

In Phase 3, CONSOL-OPTCAD will tune the design 
parameters to optimize the system to the selected perfor- 
mance criteria, and thereby select a final “best design" 
from the family of feasible solutions. Two commonly 
used performance criteria for control system optimization 
are actuator energy and feedback-loop crossover fre- 
quency, Minimizing these parameters will ensure that 
the Level 1 design specifications are achieved with the 
minimum use of control authority and minimum 
sensitivity to sensor noise. 

e. Trade-Off Studies 

The user can systematically adjust control system hard- 
ware parameters and criteria splines and then quickly 
retune the design to generate trade-off curves. For 
example, an aircraft designer can evaluate the sensitivity 
of the required actuator performance to changes in the 
aircraft agility and maneuverability requirements. If 
modest relaxation in the criteria can allow the use of a 
significantly reduced actuator bandwidth (thus lower cost 
and weight), the manufacturer may seek a waiver of the 
specification from the procuring agency. 

f. Databasing 

A focus of the ongoing CONDUIT development effort 
is the integration of a database management system to 
catalogue all CONDUIT problem definition files and 


results. The completed databasing system will greatly 
improve the organization of the CONDUIT workspace 
as compared to the simple directory structure of 
MATLAB/SIMULINK. Previous design cases and 
associated results will be accessed by a single “case 
name," allowing new cases to be rapidly generated from 
stored configurations. An array of utilities will permit the 
detailed comparison of design configurations in plotted or 
tabular form. Design parameter and performance data wall 
be plotted as a function of CONSOL-OPTCAD iteration 
to give the user maximum insight into the tuning process. 

Rotorcraft Control Law Design Study 

a. Problem Setup 

In this study, CONDUIT is used to analyze and tune the 
baseline control system for the RASCAL UH-60A fly-by- 
wire research helicopter (ref. 8) (fig. 10). The RASCAL 
control law architecture is based on the Advanced Digital 
Optical Control System (ADOCS) explicit model- 
following system (ref. 16). The schematic block diagram 
of figure 1 1 illustrates the important system elements. 

The block marked “Command Model" (M) contains the 
desired dynamic response characteristics, typically 
represented by low-order transfer functions. The block 
marked “Aircraft Dynamics" (P) is a 14 DOF linear state- 
space representation of the multi-input/multi-output 
UH-60 bare airframe dynamics and precompensation 
to improve dynamic decoupling (ref. 17). The aircraft 
dynamics model was extracted from flight test data using 
advanced frequency-domain system identification proce- 
dures specifically developed for the rotorcraft problem 
(ref. 18). Inputs to the helicopter are via the main rotor 



Figure 10. The RASCAL UH-60 helicopter. 
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Figure 11. Model-following block diagram. 


swashplate for pitch, roll, and vertical control, and the tail 
rotor pitch for yaw control. The vertical loop is not closed 
in this study because the open-loop dynamics in this axis 
are well damped and already meet the relevant handling- 
qualities requirements. The block marked "inverse plant 
model” ( P - * ) contains the inverses of low-order transfer- 
function approximations of P. If the inverse plant model 
is accurate, the aircraft will track the desired "Command 
Model” (M) response with very low bandwidth feedback 
compensation (H). The feedback compensation (H) 
contains the feedback gains and compensators for 
ensuring stability, robustness, and disturbance rejection 


and suppressing any error arising from incomplete 
cancellation by the plant inverse. 

The complete SIMULINK schematic of the RASCAL 
system is shown in figure 12. The design parameters 
consist of nine feedback gains and three model response 
parameters. The three model response parameters directly 
set the desired speed of commanded response for the 
pitch, roll, and yaw channels. The handling-quality 
specifications for this study are obtained from ADS-33C 
(ref. 2). Feedback-loop specifications are also included to 
ensure adequate levels of stability and robustness, and to 
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minimize control actuator saturation. The nine feedback 
gains are composed of three gains (proportional, integral, 
and rate) for each of the pitch, roll, and yaw channels. 
The “hard constraints” selected for this problem were 
gain and phase margin requirements for the feedback 
loops and minimum stable real part for all closed-loop 
eigenvalues. Bandwidth, quickness, coupling, and wind 
gust rejection specifications from ADS-33C (ref. 2) were 
all defined as “soft constraints.” The performance criteria 
selected were the actuator energy and feedback-loop 
crossover frequency for each of the three loops (f/e in 
fig. 11). 


b. Baseline and Optimized Design Performance 

The performance of the baseline RASCAL system design 
is shown on the CONDUIT specification w indow' in 
figure 13. The baseline design meets the Level 1 criteria 
except for the yaw bandwidth and the pitch, roll, and yaw 
quickness. CONDUIT successfully tuned the design to 
reach a “feasible solution" that achieved all hard and soft 
constraints. The Phase 3 optimized design show n in 
figure 14 minimizes the selected performance criteria 
and meets Level 1 requirements for all specifications. 
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Figure 13. RASCAL design using ADOCS gains. 
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Figure 14. Optimized RASCAL design. 


Table 1 compares the design parameter values for the 
optimized solution with the design parameter values for 
the baseline system. The baseline design does not use 
integral feedback loops; therefore, the gains for these 
loops are set to zero for the baseline design. Two 
noticeable changes for the optimized design are the 
increases in the roll and yaw command model frequency 
parameters (Mphi and Mpsi), so the associated quickness 
and bandwidth specifications could be met. Figures 15 (a) 
and 15 (b) show the supporting plot for the yaw quickness 
and yaw actuator energy specifications. The figures show 
that the yaw angle and yaw rate responses are smooth and 
do not possess any unwanted oscillations. The associated 
actuator position and rate responses (fig. 15 (b)) provide a 
complete picture of the system performance and indicate 


some degree of saturation. This information can be used 
to decide whether the actuators are sufficient for the 
system. 

The table 1 comparison also shows a large decrease in Kp 
along with an increase in the integral gain, KIphi. These 
changes allow a significant reduction ( 28 %) in the roll 
crossover frequency, without sacrificing the low fre- 
quency model tracking. There is an attendant reduction 
in roll channel phase margin. Further reduction in the 
control energy usage is limited by the pitch, roll, and yaw 
quickness specifications, which have points resting on the 
design margin borders for small attitude changes. Further 
reductions in crossover frequency are restricted by the 
wind gust rejection response, which was relaxed to the 
design margin in all three channels. 
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Table 1. Comparison of design parameters for baseline (ref. 19) and CONDUIT solution 


Design 

parameter 

Function 

Baseline value 

Final value optimized in 
CONDUIT 

Ktheta 

Pitch proportional gain 

13.6 

12.1 

Kphi 

Roll proportional gain 

8.0 

8.5 

Kpsi 

Yaw proportional gain 

7.6 

8.3 

Kq 

Pitch rate gain 

6.4 

6.4 

Kp 

Roll rate gain 

2.4 

0.28 

Kr 

Yaw rate gain 

3.2 

3.1 

KItheta 

Pitch integral gain 

0 

1.0 

KIphi 

Roll integral gain 

0 

2.3 

KIpsi 

Yaw integral gain 

0 

1.1 

Mtheta 

Pitch command model frequency 

2.0 

2.5 

Mphi 

Roll command model frequency 

2.5 

4.6 

Mpsi 

Yaw command model frequency 

2.0 

4.1 
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Figure 1 5. Supporting plots for the yaw quickness and actuator energy specifications. 
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c. Position Hold Trade-Off 

An example of how CONDUIT can be used to examine 
the trade-off between hover hold performance and actua- 
tor requirements is shown in figure 16. In this example, 
position and velocity feedback gains were tuned to reach 
various levels of hovering station-keeping accuracy, 
while the helicopter was subjected to a simulated wind 
gust time history. A position hold specification was 
employed as a soft constraint to enforce desired levels 
of station-keeping accuracy for a specified wind gust 
strength. The results show significant gains in hover hold 
performance for actuator rates of up to 2 in./sec, but little 
improvement for higher rates. 


X-29 High Performance Fixed-Wing Aircraft 
Control Law Design Study 

The X-29A (fig. 17) was an experimental aircraft flown at 
the NASA Dryden Flight Research Center to demonstrate 
the integration of several aerodynamics and controls 
technologies into a highly maneuverable aircraft. It is a 
relatively small, single-seat aircraft powered by a single 
F404-GE-400 engine. The vehicle incorporates a forward- 
swept wing and static instability to reduce trim drag and 
enhance maneuverability (ref. 20). The aircraft has three 
surfaces used for longitudinal control: all moving canards, 
symmetric wing flaperons, and aft fuselage strake flaps. 
The wing-canard planform results in a high level of 
instability that has a time-to-double amplitude near 




Figure 16 . CONDUIT studies showing trade-off of position station accuracy against required actuator rate and 
crossover frequency. 
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Figure 17. X-29A forward-swept wing fly-by-wire demonstrator. 


150 msec (ref. 21). There exist both low- and high- 
frequency instabilities resulting in a very limited 
frequency range of stability. Also, the baseline control 
system has a crossover frequency more than half the 
canard actuator mode, which if pushed a little higher 
excites the actuator frequency. 

a. X-29A Design Method and Flight Test Experience 

The X-29A control law design approach concentrated on 
maximizing robustness rather than maneuverability for 
envelope expansion flight tests. Thus, as discussed in 
detail in reference 21, initial flight tests of the X-29 
handling qualities indicated that the aircraft character- 
istics were Level 2 (adequate). The main deficiency 
reported by the pilots was sluggishness in the pitch axis. 

A design optimization effort was undertaken to determine 
if the pitch responsiveness could be improved without 
adversely affecting the controllability, thus improving the 
handling qualities of the aircraft. An optimization tech- 
nique was developed at Dryden that was based on a single 
cost function with several frequency domain derived 
components. This cost function was selected to ensure 
minimum acceptable stability levels and reasonable 
surface activity, and to minimize the closed-loop reso- 
nance and required pilot compensation, based on the 
Neal-Smith criterion (ref. 22). 

Flight test engineers were not able to reach the design 
goal of 10 deg lead compensation and 0.0 dB resonant 
peak while maintaining adequate stability margins and 
reasonable surface activity. However, the pilot lead was 
reduced by almost 50% from the original gains and the 
achieved resonant peak was below 1.0 dB for the given 


design point. The pilot comments suggested a significant 
improvement in the vehicle’s pitch response with the new 
gains. The design process showed a definite trade-off 
between the stability constraints, the surface activity, 
and the achievable Neal-Smith criterion. The resulting 
design had borderline stability margins and surface rates 
approaching the maximum capability of the system. 
CONDUIT was exercised to determine if further 
improvements in the dynamic response characteristics 
were achievable by tuning the control system design 
parameters. 

b. Problem Setup in CONDUIT 

Figure 18 shows the block diagram of the X-29 longi- 
tudinal control law created in the CONDUIT setup phase. 
The linearized models were developed and verified with 
flight test data from Dryden (ref. 9). The longitudinal 
control law uses proportional and integral compensation 
in the forward path to improve aircraft pitch responsive- 
ness. The lead-lag filter in the feedback path compensates 
for lags introduced by high-order dynamics. Stabilization 
is provided by feedback of vertical acceleration (n z ), pitch 
rate (q), and (estimated) pitch acceleration ( q ). The pitch 
acceleration is estimated using a complementary filter that 
combines the canard signal and a two-point derivative of 
pitch rate. The “g” command authority is scheduled as a 
function of Mach number, altitude, and roll rate and is 
commanded linearly with stick position. The design 
parameters chosen in this study are the four feedback 
gains (Gl, G2, G3, and G8), two PI controller gains 
(XKI1 and XKP1), two lead filter parameters (al and bl), 
and one pilot command gain (G7). Table 2 summarizes 
the purpose of these gains and their baseline values. 




Table 2. X-29A design parameters 


Design 

parameter 

Function 

Baseline 

value 

Optimized 
baseline value 

Quickness filter 
included value 

Change relative 
to baseline (%) 

XKIl 

Integral gain 

1.0 

1.4 

1.9 

91.8 

XKP 1 

Proportional gain 

0.23 

0.20 

0.18 

-20.9 

G 1 

n z feedback gain 

0.0054 

0.0054 

0.0054 

0 

G2 

q feedback gain 

-3.6 

-3.2 

- 2.1 

-40.8 

G3 

q feedback gain 

-0.18 

-0.25 

-0.25 

-37.8 

G7 

Pilot gain 

3.54 

3.8 

7.2 

103.2 

G 8 

High frequency q gain 

16.7 

15.6 

12.8 

-23.1 

al 

Quickness filter zero 

NA 

NA 

2.7 

-31.8 

bl 

Quickness filter pole 

NA 

NA 

8.3 

-31.0 

a 

Lead compensator 
parameter 

120.0 

112.6 

92.5 

-22.9 

b 

Lead compensator 
parameter 

11.0 

10.3 

8.4 

-23.6 


The “hard constraint” specifications chosen for the 
longitudinal analysis were ( 1 ) feedback-loop stability 
margins, ( 2 ) minimum stability for all closed-loop 
eigenvalues, and (3) a restriction on allowable change in 
the steady state “g/stick” response. The “soft constraint” 
specifications were (1) the Neal-Smith criterion (ref. 22), 
(2) an updated mission oriented Bandwidth requirement 
for Flight Categories A and D (ref. 13), and (3) a time- 
domain attitude quickness specification proposed in 
reference 13. The Phase 3 performance criteria were 
selected as (1) the Neal-Smith optimization specification, 
which minimizes the closed-loop resonance and required 
pilot compensation; ( 2 ) the actuator energy specification; 
and (3) the crossover frequency specification. Several 


specifications were chosen as “check only.” These 
included the Smith-Geddes criterion, the Control Antici- 
pation Parameter criterion (CAP), and the co S p, T$ 2 > Csp 
criterion. The CAP and co sp ,T 02 , £ S p parameters are 
determined in CONDUIT from a lower-order equivalent 
system (LOES) fit (ref. 3) of the complete end-to-end 
system frequency response. 

There are several advantages to the CONDUIT problem 
definition in comparison with the optimization design 
technique used by X-29 engineers. The first is that 
CONDUIT uses multi-objective optimization, which 
allows the relative importance of each specification 
to be determined by using “hard constraints,” “soft 
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constraints,” or "performance criteria" rather than a single 
cost function incorporating the requirements of several 
specifications. Second, the optimization design method 
used by the X-29 engineers was limited to the Neal-Smith 
frequency domain criterion, which depends on the linear 
system performance. This ignores the nonlinear influence 
of actuator saturation, which is captured by the time- 
domain quickness specification (ref. 13) implemented in 
the CONDUIT solution. Another important aspect of the 
CONDUIT solution was the balance of improvements in 
agility against the associated increase in actuator energy 
requirements. 

c. Baseline System Analysis in CONDUIT 

The performance of the baseline X-29 design (ref. 9) as 
determined by CONDUIT is shown in figure 19. This 
baseline design corresponds to the "Normal-Digital" 
mode for up-and-away flight control law architecture. The 
flight condition for this analysis is Mach 0.7 at an altitude 
of 20,000 ft. 


The baseline X-29 aircraft meets all the hard constraints 
except the stability margin criterion (GM = 7.9 dB, 

PM = 41.3 deg). Level 1 requirements for bandwidth 
requirement are met (soft constraint). Predicted handling 
qualities based on the Neal-Smith criterion (soft con- 
straint) are borderline Level 1. However, the pitch 
quickness (soft constraint) performance is deep in the 
Level 2 region. In addition, the Neal-Smith optimization 
criterion is far from the desired 0 dB resonance and 
10 deg pilot lead compensation. Also, the LOES based 
criteria and the Smith-Geddes criterion are also in the 
Level 2 regions. These results suggest that the pitch 
characteristics of the aircraft are inadequate. This 
corresponds well to the pilot comments concerning 
sluggish response in the pitch axis for the initial design 
(ref. " 2 1 ). 

CONDUIT was next used to determine how much of an 
improvement could be made within the confines of the 
baseline system architecture, the selected nine design 
parameters, and the available actuator authority. 
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Figure 19. Baseline X-29 A performance and handling qualities results. 
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The key concerns were to meet the stability requirements, 
improve the moderate amplitude quickness, and reduce 
the required pilot compensation. The selected perfor- 
mance criteria were: minimum actuator energy and 
minimum crossover frequency. 

d. Optimized X-29 Control System Performance 

The optimization of the X-29 control laws using 
CONDUIT revealed some interesting aspects of the 
problem as formulated. First, it was revealed that the 
feedback gain on n z (Gl) had very little effect on the 
system response, and thus degraded the progress of the 
optimization algorithm. Therefore, this value was frozen 
at its baseline value. Second, it was revealed that there 
was no solution that meets all of the problem constraints 
using the existing X-29 architecture and selected nine 
design parameters. The best solution within the existing 
architecture is shown in Figure 20. Although improve- 
ments from the baseline design are observed, the moder- 
ate amplitude quickness requirements could not be met 


using the existing architecture. The most noticeable 
improvement is the increased phase margin required to 
meet Level I stability margin requirements. The opti- 
mized baseline design parameters are listed in table 2. 

In order to address the deficiency in the response 
quickness, we included a first order lead-lag filter in the 
pilot command path. This “quickness filter” is seen in 
figure 18 with a dashed box surrounding it. Baseline 
values of 4.0 and 12.0 were chosen for the filter zero 
(dp_a) and pole (dp_b). Starting with the baseline values 
and the two added design parameters, CONDUIT was 
used to tune the eleven design parameters in the new 
architecture. With addition of the quickness filter 
CONDUIT quickly converged to an acceptable solution 
by meeting all the hard and soft constraints. With the hard 
and soft constraints met, CONDUIT reached Phase 3, and 
was further able to reduce the crossover frequency and 
actuator energy. The optimized solution including the 
quickness filter is seen in figure 21. The resulting design 
parameters and the percent change from the baseline 
design parameters are found in table 2. 
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Figure 20. Optimized X-29A performance and handling qualities results (optimized baseline). 
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Figure 21. Optimized X-29A performance and handling qualities results (with quickness filter). 


The stability margins for this design (fig. 22) are about 
the same as those achieved for the optimized baseline 
(fig. 20). However, there is now a substantial improve- 
ment in the moderate amplitude quickness (fig. 23) and 
bandwidth (fig. 24) relative to the optimized baseline. 
Figure 25 shows that the required pilot compensation 
(Lead = 16.2 deg) is about half that of the baseline system 
(Lead = 29.8 deg). As expected, the canard actuator is 
being taxed more severely; however, the system is less 
susceptible to actuator noise because the baseline 
crossover frequency (co c = 9.63 rad/sec) was reduced 
(co c = 8.99 rad/sec). The equivalent end-to-end response 
damping (fig. 26) of the optimized system has been 
reduced from £ S p = 1.46 to i^ S p = 0.895, due to the lead 
contribution of the quickness filter. 


Gm=6.372 dB. (w= 24.3) Pm=4S.7 deg. (w=9) 



Figure 22. Optimized X-29 A stability margin results. 
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Figure 23. Optimized X-29A moderate amplitude quickness requirement results. 
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Figure 25. Optimized X-29A Neal-Smith results . 
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Figure 26. Optimized X-29A LOES parameters . 


These results show that CONDUIT was able to achieve 
increased agility and improved stability margins within 
the constraint of the existing actuator authority. All of the 
desired handling quality requirements were met, including 
the "check only 7 ' criteria: Smith-Geddes, CAP, and 

w sp>T02’ ^sp* 

Summary 

L A new computational facility for aircraft flight 
control design and evaluation, CONDUIT, has been 
developed and demonstrated. CONDUIT offers a state-of- 
the-art graphical environment for integrating simulation 
models and control law architectures with design 
specifications and constraints. This tool provides 
comprehensive analysis support and design guidance to a 
knowledgeable control system designer. CONDUIT 
offers the potential for significant reduction in time and 
cost of design, analysis, and flight test optimization of 
modern flight control systems. 

2. Libraries of preprogrammed specifications for 
rotorcraft, fixed-wing aircraft, and servo-loop design are 
rapidly configured to the user’s design problem. Compli- 
ance with all of the active specifications is graphically 
displayed on the criteria with a single pushbutton 
command, thus significantly streamlining the system 
evaluation process. A comprehensive set of supporting 
plots is available for each specification, thereby giving 


the analyst rapid insight into the control system behavior. 
A state-of-the-art multi-objective function optimization 
environment (CONSOL-OPTCAD) is integrated in 
CONDUIT to allow the user to tune selected design 
parameters (e.g., gains, time constants) for compliance 
with the active design specifications and selected 
performance specifications. 

3. Case study applications to complex rotary- and 
fixed-wing flight control problems were presented. In 
the helicopter example, the baseline RASCAL UH-60 
control system, as provided by the flight control 
contractor, is evaluated versus the ADS-33C handling- 
quality specifications. Then the selectable system gains 
are optimized to meet all system performance and 
handling-qualities specifications. In the X-29 fixed-wing 
example, CONDUIT analyses show that the handling 
qualities for the baseline control system exhibit poor 
quickness and inadequate stability margins. No significant 
improvement in quickness is achievable by adjusting the 
controller parameters for the baseline control law 
architecture. The inclusion of a quickness filter in the 
pilot command path provides an additional degree of 
freedom for control system tuning. CONDUIT success- 
fully exploits the trade-off between forward loop and 
feedback dynamics to significantly improve the expected 
handling qualities and stability robustness. 
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